All Databases MacTech Vol 02-1986

Hello World

Volume Number: 2

Issue Number: 5

Column Tag: The ABC's of C

Starting with Hello World

By Bob Gordon, Apropos Publications, Minneapolis, MN

Welcome to How to C. This series will explore use of the C language on the

Macintosh for those who don't know C and may have fairly limited experience

programming the Mac. Put another way, if you often have the feeling that you don't

know what's going on, this is a place to get your bearings.

You'll find the following items useful to have around if you want to do more than

program vicariously:

• Using the Macintosh Toolbox with C by Takatsuka, Huxham, and Burnard

(Sybex, 1986). This will serve as our 'text.' It is currently the best available

book on C on the Mac. We will generally follow their order of topics.

• The C Programming Language by Kernighan and Ritchie (Prentice-Hall, 1978).

If you are going to use C, you need this book. It is an amazingly clear and concise

discussion of the language.

• Inside Macintosh. Mainly because the first book does not cover everything.

• A C development system. A number of compilers are available. We'll focus on

Consulair's Mac C because the Using the Macintosh Toolbox book uses it, and

because it uses MDS. If you're using a different compiler, don't worry. C is one of

the more portable languages (between compilers and machines), and I'll try to

point out differences when they appear.

I'll also mention other useful sources of which I am aware. If you have any

favorite books or articles, send me a note so we can share the information.

Why Use C / Why Not Use C

C was designed to be suitable for systems programming. As such, it is very

flexible and allows programmers to do pretty much as they please. C is often

characterized as a 'medium level' language. It offers the control mechanisms and data

structures of a higher level language but at the same time allows access to the hardware

and the ability to handle data in any way that seems suitable at the time. The compilers

typically generate fairly fast, compact code.

This flexibility is not without its costs, however. It is very easy to make a real

mess of things (and generate incendiary devices on the Macintosh) by not getting the

types of parameters correct. And some C notation can be downright cryptic. It is easy

to make C code unreadable.

In spite of the problems, I prefer C to Pascal. I could usually do what I wanted

with Pascal (depending on the compiler), but I knew I was cheating. And I could never

be sure the technique would work the same way with a different compiler.

Problems Using C on the Macintosh

One problem with C vis-à-vis the Macintosh is that much of the C literature and

many of the standard library functions assume you are using Unix or a Unix-like

operating system. As you may have noticed, the Macintosh does not. This poses an

additional set of problems for learning C on the Mac. The compiler makers follow two

approaches. Some ignore Unix; others make the Mac look like it's running Unix.

A second problem is that the Macintosh operating system assumes applications

will be written in Pascal. This presents problems in at least two areas: strings and

parameter passing.

A C string is an array of bytes with a terminating zero (a byte of all zero bits, a

binary zero, the null character, represented in C by \0). A Pascal string, as far as the

Macintosh is concerned, is an array of bytes consisting of a leading byte containing the

number of bytes in the string followed by the bytes of the string. Obviously sending a C

string to a Toolbox function is not going to yield any sort of desired result. The

compiler makers have solved this problem in two ways. Some compilers automatically

convert the string when its passed; others provide a C function to do the conversion that

you call before calling the Toolbox function (and another function to reconvert the

string). Check your compiler's documentation to see what it does.

The parameter passing problem involves a number of issues: where parameters

are passed (stack or registers), the order in which they are passed, and how complex

data types are passed. Most of the time you need not to be concerned with this at all;

your compiler will do the necessary translations. In some cases (with some compilers)

you must be aware of the difference.

Getting Started

The first program we'll do is the first program in Kernighan and Ritchie. This

will force us to figure out how to set up our compiler, and use the editor, compiler, and

linker. Now, at this point I should simply recount my experiences in getting "hello,

world" to appear on my screen. Unhappily, I only recently received the compiler so I

haven't done it yet. I also do not have two Macs so excuse me while I figure this out.

This month I've got Mac C™ from Consulair. It comes with three booklets of

documentation, a letter from the author Bill Duvall, and some information sheets. One

sheet describes the contents of the four disks. They include a public domain ram disk

program written in Mac C called RamStart, so the first thing I did was to set up a ram

disk.

Using RamStart is a bit exciting. A help button is available, but if you don't click

it fast enough, RamStart goes ahead and makes the ram disk. I don't remember exactly

how I found that out: it is, of course, in the instructions, but you can't read the

instructions unless you click help. Catch 22. Actually, the program is quite easy to

use. Simply put what you want in the ram disk in the same folder with RamStart, and it

creates the disk with those files in it. With Mac C, you may not have a ram disk larger

than 280 K bytes (on a 512 K machine) or the compiler will run out of room.

The Mac C package includes Edit, the four window mouse-driven program editor.

Edit allows transferring directly to the compiler so you can invoke the compiler

directly from Edit.

hello, world

Using Edit, I typed in the first program most people learning C try, a program to

print "hello, world" on the screen.

#include "stdio.h

/* traditional first C program */

main()

{

printf("hello, world");

}

That's the program. If you have never seen a C program before, there is a lot to

examine even in this.

The first line specifies an include file. This is a separate file that you wish to

include as part of the compilation. These files typically contain constants, references

to external functions, new symbols, and macros, but they can contain any code you wish

to include.

Here are some parts of the stdio.h that comes with Mac C:

// stdio.h

The double slash means comment to the end of the line. This is not standard.

// Aug 30, 1984 2:43 PM: New File

// Standard UNIX IO library defs for MacC

#define ERROR -1

#define EOF -1

#define NULL 0

#define MAXLINE 255

#define FILE int

The defines are instructions to the C preprocessor. These supply names to some

oft-used values. In a program, you can use the name and the preprocessor will replace

it with the value. By the way, standard C practice requires the "#" be in the first

column. Mac C allows it anywhere on the line as long at is is preceded only by white

space.

// Standard Routines

extern char putchar();

extern char fputc();

extern long putl();

extern int printf(...);

There are references to external functions. External functions are functions

defined in another file. For the compiler to work correctly, it needs to know the type of

object returned, if any. Here we see that putchar returns a type char, putl returns a

long, and printf returns an int. Most C compilers have a separate include file for each

chapter in Inside Macintosh to provide the necessary definitions.

To return to our program, the next line is:

/* traditional first C program */

This is a comment. The "/* */" bracket comments.

main()

Every C program must have one and only one main function. It is where

execution starts. Function names always have parentheses after them even if they have

no parameters.

{

printf("hello,world");

}

The braces define a block of code that is handled as one line for program control

purposes. They are similar to Pascal's begin-end.

The only piece of code that does anything here is printf. It is used to write

strings on the screen (the standard output device). It is not actually part of the

language but is part of the standard library. The semicolon is a line terminator.

A few comments are in order concerning other compilers. Mac C creates a TTY

window for the standard C I/O functions. Other compilers may write directly to the desk

top or require that you create a window for them. You will have to check the

documentation.

Next month we'll look at some more basic C concepts and start dealing with using

C in the Macintosh environment.

Referenced by (28):